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SYSTEM AND METHOD FOR MANAGING AND PROVISIONING 
VIRTUAL ROUTERS 

Field 

5 The present invention relates generally to computer network routers, and 

more particularly to systems and metbods of managing virtual routers. 

Copyright Notice/Permission 
A portion of the disclosure of this patent document contains material that 
10 is subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or the patent disclosure 
as it appears m the Patent and Trademark Office patent file or records, but 
otherwise reserves all copyright rights whatsoever. The following notice applies 
to the software and data as described below and in the drawings hereto: 
15 Copyright © 2000, CoSine Communications, Inc. All Rights Reserved. 

Background 

The interest in the deployment of virtual private networks (VPNs) across 
IP backbone facilities is growmg every-day. In general, VPNs fall into two 
categories: CPE-based (Customer Provided Equipment) VPNs and network- 
based VPNs. 

With CPE-based VPNs, the ISP network provides only layer 2 
connectivity to the customer. The CPE router takes ownership of setting up 
tumiels and handling routing with other sites. Network-based VPNs consist of a 
mesh of tinmels between ISP routers. They also have the routing capabilities 
required to forward traffic &om each customer site. Each ISP router has a VPN- 
specific forwardmg table that contains VPN member sites. The benefit offered 
by network-based VPNs is that the ISP is responsible for routing configuration 
and timnel setup, hi addition, other services, such as firewall, Quality of Service 
(QOS) processing, virus scanning, and intiiision detection can be handled by a 
small number of ISP routers. New services can be introduced and managed 
without the need to upgrade CPE devices. 

There are typically three steps to buildmg a VPN's infirastructare: 
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1) Define a topology and create tuimels using IPSec, LT2P, 
PPTP,GRE,orMPLS. 

2) Configure routing on the edge routers to disseminate site- 
and intra- VPN reachability infonnation. 

5 3) Enable such services as firewall, QOS, and so forth. 

Usually, IP network managers use the following model for building and 
maintaining their networks: 

1) With the help of some network experts, design the 
network. 

10 2) Use the command line interface (CLI) or ASCII 

configiiration files to define the routing configuration. 

3) Use trial-and-error method to detemune a working 
solution for the network configuration. 

4) Manually manage configuration files for routers. 

1 5 The process of building or changing a network requires significant 

manual effort, and is slow, expensive, and error-prone. For ISPs that plan to 
provide VPN sei-vices, tliis model for provisioning VPNs is problematic. ISPs 
need to configure routing for VPNs, each of which can be considered separate 
networks. 

20 As noted above, building and managing one network is difficult, tlie 

problem is made much worse when the ISP must build and manage thousands of 
networks. For ISPs to succeed at this, a facilitation firamework is required. 
As a result, there is a need in the art for the present invention. 

25 Summary 

The above-mentioned shortcomings, disadvantages and problems are 
addressed by the present invention, which will be understood by reading and 
studying the foUovmg specification. 

To enable ISPs to deliver services using service processuig switches, 
30 systems and methods are provided that make provisioning VPNs very easy. The 
systems and methods described reduce the resources required to provision and 
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manage a VPN network. For example, it is possible for ISPs to provision 
thousands of VPNs, each with a vaiiety of services. The routing is a component 
of the VPN infrastructure. 

In one embodiment of the invention, site reachability infoimation is 
determined for a service processing switch that is conimunicably coupled to one 
or more sites. In addition, global routing profiles, customer site profiles and 
OSPF profiles are defined. Tlie profile data, in addition to or instead of the 
reachability infoi-mation is used to generate routing configuration data for one or 
more Virtual Routers and Virtual Private Networks implemented within the 
service processing switch. 

The present invention describes systems, clients, servers, methods, and 
computer-readable media of varying scope. In addition to the aspects and 
advantages of the present invention described in this summary, fiirther aspects 
and advantages of the invention will become apparent by reference to the 
drawings and by reading the detailed description that follows. 

Brief Description Of The Drawing s 

FIG. 1 is a block diagram of the hardware and operating enviiment in which 

different embodiments of the invention can be practiced; 
FIG. 2 is a diagram illustrating an exemplary Virtual Private Network used in 

embodiments of the invention ; 
FIG. 3 is a diagram illustrating further details segments of an exemplary Virtual 

Private Network used in embodiments of the invention; 
FIG. 4 is a diagram illustrating Inter-VPN reachability; and 
FIG. 5 is a diagram illustrating dynamic intra- VPN routing; and 
FIG. 6 is a flowchart illustrating a method for provisioning a router configuration 

according to an embodiment of the invention. 

Detailed Descrip tinn 

In the following detailed description of exempbjy embodiments of the 
3 
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inveation, reference is made to the accompanying drawings which form a part 
hereof, and in which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. These embodiments axe 
described in sufficient detail to enable those skilled in the art to practice the 

5 invention, and it is to be understood that other embodiments may be utiUzed and 
that logical, mechanical, electrical and other changes may be made without 
departing from the scope of tihe present invention. The following detailed 
description is, therefore, not to be taken in a limiting sease. 

In the Figures, the same reference number is used throughout to refer to 

10 an identical component which appears in multiple Figures. Signals and 

comiections may be referred to by the same refereace number or label, and the 
actual meaning will be clear from its use in the context of the description. 

The detailed description is divided into multiple sections. In the first 
section the hardware and operating environment of different embodiments of the 

15 invention is described. In the second section, the software environment of 
varying embodiments of the invention is described. In the final section, a 
conclusion is provided. 

Hardware and Operating Enviromnent 

20 

FIG. 1 is a diagram of the hardware and operating environment in 
conjunction with which embodiments of the invention may be practiced. The 
description of FIG. 1 is intended to provide a brief, general description of 

suitable computer routing hardware and a suitable computing environment in 
25 conjunction with which the invention may be implemented. Although not 
required, the invention is described in the general context of computer- 
executable instructions, such as program modules, being executed by a 
computer, such as a personal computer or a server computer. Generally, 
program modules include routines, programs, objects, components, data 
30 structures, etc., that perform particular teisks or implement particular abstract data 
types. 
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As shown in FIG. 1, the system 100 includes a service processing switch 
1 10, access routers 104, service management system 118, and customer network 
management system 106. In some embodiments, service processing switch 110 
provides switching, routing and computing resources that can be allocated by a 
5 service provider to customers. In one embodiment, the service processing switch 
110 is the IPSX 9000 service processing switch from CoSine Communications, 
Inc. However, the mvention is not limited to any particular switch, router or 
service processing hardware. 

Service processing switch can contain one or more blades 1 12. In some 

1 0 embodiments of the invention, blades 1 12 have a type associated with them. 
Examples of blade types include, processing functions such as network blades, 
control blades, trunk blades, and processor blades. Network blades provide 
interfaces to different types of networks. Control blades provide system 
management and accounting functions to the service processing system 110. 

15 Tixmlc blades provide access to high speed trunlc networks. Processor blades 
provide general purpose computer processors that in some embodunents of tlie 
mvention provide firewall, intrusion detection, or directory semces. Blades are 
communicabiy coupled to one another, in one embodiment a packet ring is used 
to couple the blades. 

20 In some embodunents, each of blades 1 12 mcludes one more processing 

elements 1 14. Processing elements 1 14 include CPU and memory that provide 
computing resources for Ihe blade. The mvention is not limited to any particular 
number of processmg elements on a blade, nor.is the invention limited to any 
particular number of blades in a service processmg switch 1 1 0. 

25 Service processing system 1 1 0 is typically communicabiy coupled to a 

network 116, for example the hitemet. Network 1 16 can also be a Wide Ai-ea 
Network (WAN), a Local Area Network (LAN), or a private network. 

Sei-vice processing system 110 is also typically communicabiy coupled to 
a plurality of customer networks 102 via customer access routers 104. 

30 Service mauagement system 1 1 8 hosts software that is used to configure 

and control the operation of service processmg switch 110. hi one embodiment 
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of the invention, the service management system is a SPARC system available 
j&om Sun Microsystems, Inc. running the InVision product fix>m CoSine 
Communications, Inc. Service management system 11 8 can be used to allocate 
resources within service processing switch 110 to various customers. In one 

. 5 embodiment of the invention, sei-vice management system 118 communicates 
with service processing switch 110 using the Simple Network Management 
Protocol (SNMP). The operation of service management system 118 will be 
described in ftirther detail in the sections that follow. 

Customer network management system 106 hosts software that 

10 configures and controls the resources within service processing svdtch 1 10 that 
have been allocated to the particular customer. The operation of service 
management system 118 will be described in further detail in the sections that 
follow. 

Those skilled in tiie art will appreciate tiiat the invention may be 
15 practiced with other routing system hardware configurations besides those 
described above. 

Software Environment 
The embodiments of the invention include a software enviroimient of 

20 systems and methods that provide a mechanism for simplifying the provisioning 
and management of VPN (Virtual Private Networks) and VRs (Virtual Routers) 
within a service processing switch. The embodiments of the invention provide a 
policy-based mechanism for network provisioning. Thus a service provider, for 
example, an ISP (Intemet Service Provider), managing a service processing 

25 switch can create various service policies, which are used in defining VPN 

profiles. These profiles are used to automatically generate tunnels, routing, and 
other service configurations for VPNs. Resources within switch 110 such as 
blades and processing elements are allocated by a service provider to one or 
more customers, who then can configure those elements allocated to it. 

30 Configuration from the service provider' s perspective, and from the customer's 
perspective can be driven based on profiles. 
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20 



FIG. 2 provides an illustration of a VPN as used in various embodiments 
of the invention. A VPN is typically a logical grouping of virtual routers (VRs) 
206. The connectivity between VPNs and customer sites 202 is provided by 
means of virtual interfaces (Vis). Users can create Vis and comect them to 
customer sites or to Vis of other VRs. The virtual connection can also be 
configured to be a tunnel interface (TI) to a type of secured tunnel, such as an 
IPSec tiimiel. Customer sites can be connected via a network interfece 204, 
which can be a leased line interfece such as DS3. The invention is not limited to 
any particular type of network interface. 

Ill some embodiments of the invention, two types of virtual routers are 
supported: Customer VRs and ISP VRs. Customer VRs are used to buUd 
customei- VPNs, and ISP VRs are used to build ISP VPN. The ISP VPN is 
connected to an ISP backbone network 310 (FIG. 3). In this fiamework, each ISP 
needs only one ISP VPN. Customer VRs can be connected to the ISP VPN by 
means of Vis. Every virtual router can use one or more routing protocols, 
including STATIC, RIP, OSPF, and BGP, to dissemmate reachability 
information. For routing purposes, every VPN based on this framework can be 
t-eated as an extension of the customer network. 

The embodiments of the invention allow network managers to define 
profiles. The profile information is used to automatically generate the routing 
configuration for a VPN. In some embodiments, to profile the routing on a VPN, 
a customer VPN is divided into three segments, wliich are Ulustrated in FIG. 3. 

ISP-Edge segment 306 is a VPN segment tlaat connects the VPN to 
customer sites. This segment includes all virtual interfaces connected to logical 
interfaces and hinnel interfaces whose remote end is outside the VPN. This 
segment is used for disseminating customer site reachability infonnation. 

Inside-VPN segment 304 (also referred to as an Intra-VPN segment) is a 
VPN segment that provides comiectivity among different VRs 206. This -segment 
is used to disseminate intra-VPN reachability information. 
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Inter- VPN segment 302 is a VPN segment that connects different types 
of VPNs; for example, the interfaces that connect a customer VPN with an ISP 
VPN. 

It is desirable to identify segment types, because it provides a mechanism 
5 for generating profiles that can be optimized depending on the segment type. 

Profile-Based Routing Configuration 

FIG. 4 illustrates how the routing needs of the Inter- VPN segment 302 
10 are taken care of at the time a VR is created. When a customer VR 206 is 

created, the user is given the option to automatically connect the VR with an ISP 
VR 308. At that time, service management system 1 1 8 (FIG. 1) also creates a 
default route 402 on the customer VR206 and a static route 406 on the ISP VR 
308, which accommodates customer VR 206 to ISP VR 308 connectivity. In this 
15 model, for all network address translation (NAT) addresses 404, the user must 
add static routes on the ISP VPN. 



The profile discussed here takes care of the first two VPN segments: ISP- 
Edge 306 and Intra-VPN 304. Given a VPN's routing requirements, there ai-e 
typically three routing aspects that are considered: 

1) The routing protocol that should be turned on a virtual interface in 
aVR 

2) When and how to redistribute routes between various routing 
protocols. 

3) When enabling a routing protocol on a router or interface, the 
routing parameters to use for optimizing performance. 

Service management system 118 (FIG, 1) uses VPN profile data to 
automatically generate the required routing configuration. In some embodiments 
of the invention BGP (Border Gateway Protocol) is excluded as a possible 
choice for configuring customer VPNs. There are a few reasons for tliis. Fkst, 
there are only two cases in which BGP would be used in a VPN environment. 
ISP-VPNs might use BGP to talk to the Internet core. Also, if a VPN connects 
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two very large customer sites, IBGP might be needed for the Intra-VPN segment 
to ensure scalability. There will generally be very few ISP VPNs (in most 
networks, there is only one), and it's unlikely that a VPN will be used to connect 
two or more large sites. 

The second reason for excluding BGP firom the profile is the VR-specific 
customization tliat is required to make BGP work in a VPN environment. 
Because BGP connects ISP VRs to the ISP core, a careful selection of export and 
import policies is needed to minimize the number of routes in each ISP VR. It is 
very difficult to represent this type of configuration by means of a generic 
routing profile. Service management system 118 (FIG. 1) provides an interface 
to configure BGP on VRs. This interface allows user to enable BGP on a VR, set 
its BGP neighbors, and add import and export policies. 

In some embodiments of the invention, the profile defines a simple 
routing configuration, that is, static routing for the Intra-VPN segment. Thus 
static routing will be used to communicate witli each customer site. This 
configuration is deshrable because it puts a minimum load on the device, thus 
increasing the number of VPNs that can be managed by each service processmg 
switch 110. 

There are two issues witli static routmg. First, ISPs need to manage static 
routes for each customer. As new subnets are added to customer networks and 
old ones are removed, the static routes corresponding to these subnets should be 
added or removed in the correspondmg VPNs. In some embodiments, this 
problem can be solved by having service management system 1 18 (FIG. 1) takes 
ownership of automatically managing static routes based on the customer site 
subnet information. In these cases, customers can directly add or remove subnet 
information using tools such as the customer network management system 106 
(FIG. 1). This capability will transfer the ownership of managing routing to 
customers. 

A second issue with static routing is that the routing by definition is 
STATIC. If a site interface is down,- ti-affic cannot be re-routed to an alternate 
path. A partial solution to this problem can be provided by allowmg customer to 
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disable routing on a site that is down. This can be done by means of a customer 
network maaaagement system 1 06 (FIG. 1). In this scenario, service management 
system 118 (FIG. 1) would remove the static routes Scorn the network that 
belongs to the site that is down. This action would allow the traffic to go through 
5 tlie baclcup path. 

To resolve the two issues described above, the embodiments of the 
invention provide a mechanism for a user to choose more advanced routing 
options in projSles. For smaller sites, a viable option is RIP (Routing Infomiation 
Protocol), wliile for large sites operators might choose OSPF (Open Shortest 

1 0 Path First gateway protocol). The dynamic routing transfers the burden of 
managing route changes firom the network manager to the device. If a user 
selects d)Tiamic routing at the edge, then the service management system will 
also have to use dynamic routing to disseminate Mra-VPN reachability 
information. FIG. 5 illustrates tliis scenario. If a site link to virtual router A 

15 206.1 is down, virtual router B 206.2 will kiiow that the traffic going through 
that link needs to be rerouted to virtual router C 206.3 only if dynamic routing is 
specified for Intra- VPN segment 504. 

If all the sites (ISP-Edge segment) are using static or RIP routing, service 
management system 118 will allow the user to choose between RIP and OSPF 

20 for Intra-VPN routing. The user v^oll typically select RIP if there are relatively 
few VRs in the VPN. Because OSPF is more scalable, it is a logical choice for 
bigger VPNs. If a user decides to ran OSPF at a site edge, it is desirable to select 
OSPF for the Intra-VPN segment. 

This section has described the various software components in a system 

25 that provides for the automatic generation and provisioning of routing 

configurations. As those of skill in the art will appreciate, the software can be 
written in any of a number of programming languages knovm in the art, 
mcluding but not limited to C/C-H-, Java, Visual Basic, Smalltalk, Pascal, Ada 
and similar programming languages. The invention is not limited to any 

30 particular programming language for implementation. 
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Mefliods For Performmf ? Profile-Based Routing Co nfiguration 

In the previous section, a system level overviews of the operation of 
exemplary embodiments of the invention were described. In tliis section, the 
particular methods of the invention performed by an operating environment 
executing an exemplary embodiment are described by reference to a flowchart 
shown in FIG. 6. The mefliods to be performed by the operating environment 
constitute computer programs made up of computer-executable instructions. 
Describing the mefliods by reference to a flowchart enables one skilled in the art 
to develop such programs including such instructions to cany out the methods 
on suitable computers (the processor of the computer executing the instructions 
firom computer-readable media). The method illustrated in FIG. 6 is inclusive of 
the acts required to be talcen by an operating envhoiment executing an 
exemplary embodiment of the invention. 

The method begins at block 602 when a system executing the method 
learns, or discovers, the current routes to sites connected via the service 
processmg switch 118 (FIG. 1). To build or include new sites in a VPN, each 
edge router must leam the routes to all sites connected to all tlie edges in the 
network. An edge in a network is a boundary between two routers, an edge 
router is a typically network device that routes data between one or more local 
area networks backbone network. Two components of routing information are 
typically needed for the VPN: 

1) Site Reachability Information: Each edge router needs to leam the set of 
VPN addresses and address prefixes reachable at each site. The 
reachability uiformation needed by the CPE (Customer Provided 
Equipment) router depends on site configuration. Customer sites axe 
charactenzed mto two categories: stub sites and noii-stub sites. The CPE 
routers of stub sites have default routes pointmg to an ISP edge router 
while the CPE router of non-stub site do not, and therefor need to loiow 
the set of non-local destmations reachable via that linlc. Usually, if a VPN 
also provides hitemet connectivity to a site and there is no backdoor 
connection between this and any other site, it is a stub site. 
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2) Intra- VPN Reachability Infomiation: Once an edge router has learned the 
set of prefixes associated with each of its customer site' s links, tliis 
information must be disseminated to each other router in the VPN. 

5 After learning routes to sites, the system disseminates site reachability 

information (block 604). Various embodiments of the invention employ 
different mechanisms to disseminate the information. In one embodunent, static 
configuration is used. In static configuration, all the subnets associated with 
each customer site are manually configured into the VPN. To increase the 

10 manageability of this information, customer network management (CNM) 116 
(FIG. 1) tools can be enhanced to allow customers to directly add and remove 
subnet information firom the VPN. The subnet information can be used to 
automatically create the static routes in the VPN. In this case, the customer also 
needs to add static routes to the CPE routers of non-stub sites. 

15 In an alternative embodiment, dii-ectory lookup is used to disseminate the 

site routing information. A cenlaral directory server can maintain the identities of 
edge routers associated with a VPN, and the set of customer site links bound to 
the VPN per edge router. Each edge router can query this information using 
some defined mechanism (for example, LDAP) upon startup. This mechanism 

20 requires some Idnd of database synchronization mechanism in order for all edge 
routers to leani the addition and deletion of sites from the VPN. 

In a further alternative embodiment, a routing protocol can be run 
between the CPE edge router and tlie ISP edge router to exchange reachability 
information. This allows an ISP edge router to leam the prefixes that can be 

25 reached at a customer site, and enables a CPE router to leam the destinations that 
can be reached via the providernetwork. 

• In a still further embodiment, if a CPE router runs Multiprotocol Label 
Switching (MPLS), the MPLS LDP (Label Distribution Protocol) can be 
extended to convey the set of prefixes at each stub site, together with the 

30 appropriate labeling information. 

In addition to the above, several mechanisms for Disseminating hitra- 
VPN Reachability Information can be used. In one embodunent employing 
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Static configuration. The service management system 118 can use the subnets 
configured for each site to automatically create static routes for dissemination of 
intra-VPN reachabiUty information.. 

In an alternative embodiment, directoiy lookup information is used. In 
addition to VPN membership information, a ceutral directory can maintain a 
hsting of tlie address prefixes associated v^rith each end point. 

In a fui-ther alternative embodiment, each edge router runs an instance of 
a routing protocol on each VPN to disseminate intra-VPN reachabiUty 
information. Usmg tins mechanism, both fiiU-mesh and arbitrary, VPN 
topologies can be easily supported. 

A still fiuther alternative embodiment uses a Link ReachabiUty Protocol. 
Here each edge router can run a link reachabiUty protocol carrying the necessary 
mfoimation. This protocol runs across the tiinnel between the two edge routers. 
The two preferred choices for this approach are a variation of MPLS LDP and 
IBGP. The link reachabiUty protocol-based schemes can support only fiiUy 
meshed VPNs. 

In yet a further alternative embodiment, site reachability infomiation is 
disseminated by Piggybacking on IP Backbone Routing Protocols. The set of 
address prefixes associated with each stub mterface can also be piggybacked into 
tiie routing advertisements from each edge router and propagated through the 
network. Other edge routers extract tiiis information from received route 
advertisements. This scheme typically requires that mteimediate routers cache 
intra-VPN routing information to propagate the data fimher. TMs also has 
impUcations for the level of security possible for intra-VPN routing infomiation. 

In addition to learning and disseminating site reachability infomation, a 
global routing profile can be defined (block 606). hi one embodiment of the 
invention, the global routing profile includes the following parameters: 

a. Routing administration status 

b. Routing protocol for Ultra- VPN segments 

c. Default routing protocol at the ISP edge. All the customer 
sites wiU generally inherit tiiis. 

d. Default site type: stub or non-stub: Stub sites have a default 
route going toward tiie ISP VPN (hitemet). For stub sites, 

13 
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there is no need to export routes from the VPN. This 
information is used in creatiag default export and import 
policies. 

e. If the routing protocol for the Intra- VPN segment is OSPF, 
define the OSPF profile topology type. 

When a site is added, it inherits the routing configuration fi-om the 
routing profile. 

In addition, the system provides for the definition of a custom site profile 
(block 608) Multiple types of site information can be configured. First, if the site 
routing profile needs to be customized, the user may do so. Second, if a user 
wants static routing at the edge, the network subnets that are associated with the 
site must be provided. This configuration will allow the service management 
system to automatically create static routes. In one embodiment of the invention, 
the site profile contains following parameters: 

a. Routing Protocol at the ISP edge 

b. Site Type: stub or non-stub 

c. OSPF Area ID: IfOSPF is enabled at the edge 

d. Site subnets. 

In addition, a custom OSPF profile can be defined (block 610). When a 
user configures a routing profile, service management system 118 (FIG. 1) 
automatically generates OSPF, RIP, and static profiles, if needed. In many cases, 
the user will want to customize the generic OSPF profile. The user can 
customize the generated profile using a policy-based profile configuration 
workflow. The workflow includes the following features: 

1) The user can define custom OSPF areas. He only needs to configure what 
VRs are included in what areas; Service management system 1 18 (FIG. 
1) generates the required configuration for each VR and VI. 

2) The user can define a route aggregation policy for an OSPF area; Service 
management system 118 (FIG. 1) wiU auto-generate this configuration 
for all the VRs in that area. 



3) By default, Seivice management system 118 (FIG. 1) generates one VR 
routing parameter policy, which applies to aU VRs, and three VI routing 
40 parameter poUcies which apply to tuimel interfaces, customer site edges. 
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and VI- VI connections. AVhen routing configuration is generated, these 
policies are used to define routing parameters. The user can malce 
changes m any of these policies, or create his own poUcies and assign 
them as defaults. The user also can define pohcies and set them to be 
appUed on a set of VRs or Vis. Service management system 1 18 (FIG 1) 
allows users to individuaUy customize parameters for a VR or VI. 

When configuring OSPF for intra-VPN segment, the service management 
system caimot use the same guidelines as those used in setting up a normal 
OSPF network, because each router in a VPN is a virtual router. To optimize 
performance, it is desirable to minimize the size of the routing table. This can be 
accomphshed by keepmg the OSPF aieas small, hi a nomial OSPF network, the 
network manager would not let the size of an OSPF area grow beyond 50-60 
routers. With a VPN, it is desirable to not let the OSPF area grow beyond 20-25 
VRs. The larger the OSPF area, the higher' the load on each VR, and hence the 
fewer the VRs that can be created on the service processing switch. As a result, it 
is not desirable to malce a complete mesh of all the VRs in a large VPN. The user 
should use a custom OSPF topology and create areas of reasonable size to ensure 
scalability and stabiUty of the OSPF network. 

The system also provides for the definition of custom export/import 
poUcies (block 612). Using the router and site profile defined above, sei-vice 
management system U 8 (FIG. 1) generates default policies necessary for 
different routmg protocols to talk to each other, hi some situations, custom 
export and unport policies are needed to control access to critical networks. The 
system allows users to add custom export and import pohcies. 

Based on the site reachability information and/or the- global and custom 
profiles described above, the service management system generates routing 
configuration (block 614). Described below are items that are considered during 
the generation of the configuration: 

• The user can only configure one protocol for the hitra-VPN segment 
This configuration is used to configm-e the routiaig on all the 
mterfaces that comiect one VR to another in the same VPN. hi most 
cases, this takes care of all humel mterfaces. 
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If the user selects static routing for a site, service management system 
118 (FIG. 1) win auto-generate one static route per site subnet on the 
local VR. If the routing for the Intra-VPN segment is also static, 
service management system 118 (FIG. 1) will also generate one static 
route per subnet on each remote VR. Auto-generation of static routes 
assumes a meshed-topology for the VPN. If tlie topology is not 
meshed, some additional configuration may be needed for the routing 
to work. 

If select dynamic routing is selected for the Intra-VPN segment, 
service management system 118 (FIG. 1) auto-generates export 
policies to disseminate site reachability information to other VRs. 

For a non-stub site that is using dynamic routing to communicate 
with the VPN, service management system 118 (FIG. 1) will create 
an export policy to inject all the routes learned from the Ihtra-VPN 
segment's routing into the customer network. 

If the user selects a custom OSPF topology for the Intra-VPN 
segment, he does not have to explicitly assign an area ID for each 
interface. Service management system 118 (FIG. 1) automatically 
interprets this information from the area configuration. 

Once the profile is set. Service management system 118 (FIG. 1) 
automatically handles the routing configuration for the addition and 
deletion of VRs and Vis. For example, if standard OSPF routing has 
been selected for the Intra-VPN segment, whenever the user creates 
an IPSec tunnel connecting two VRs, OSPF will be enabled with area 
ID 0.0.0.0. 

If a VPN is using only one routing protocol for the Intra-VPN 
segment, service management system 118 (FIG. 1) can discover 
routing profiles firom the device configuration. 

Service management system 118 (FIG. 1) supports explicit two-phase 
provisioning of routing profile configurations. In the first phase, the 
user makes changes to the routing profile and saves them in the 
database. In the second phase, the user commits the profile to the 
network. In this phase, the server translates delta changes in the 
profile configuration into a required low-level configuration and 
pushes it to appropriate devices. 

Service management system 118 (FIG. 1) allows users to temporarily 
remove routing configurations from the device. Users can do this by 
providing administration status attributes for the routing profile. 
Settmg this attribute to a "disabled" state and committing the profile 
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removes configurations from the device. Routing can be turned on 
again by setting the admin status to "enabled." 



As can be seen from the above, tlie generated and customized 
can act as templates that can be applied to particular VPNs, particular VRs, or 
groups of VRs. For example, assume an existing policy has been changed or 
further customized. In one embodiment of ttie invention, the user is presented 
with a list of VRs or VPNs that were configured with the existing policy. The 
user can tiien select the VRs to which the new policy should be appHed. 

Similarly, assume that the user wishes to change the policy for a 
particular VR. In one embodiment of the invention, the user selects the desired 
VR, and tiien selects a new poUcy to be apphed to the VR. The new poHcy can 
then be appHed immediately, or it can be applied at a later scheduled time. 

In addition, the policies can be used as a differentiator in providing VPN 
services. If user selects STATIC routing for ISP-Edge and Intra-VPN segments, 
the seivice processing switch does not need to run any routing instances per 
customer VR. On the other hand, if a user has chosen to run dynamic routing for 
hitra-VPN and ISP edge segments, the switch may have to run instances of 
routing protocols such as OSPF and RIP. Running routing instances on virtual 
routers consumes both processing power and memory on the processing 
elements and blades. The demand on the resources will depend on the size of 
VPN and its interaction witli various customer sites. An ISP can recover the cost 
of the increased resource usage, by using routing as a differentiator in providing 
VPN services. There are few methods of providuig sei-vices: 

1) Allow user to select the routing protocol per site: STATIC, RIP, or 
OSPF. Based on the site configui-ation, ISP can automatically configme 
routing protocol for intra-VPN segment. The cost of tlie service should be 
the lowest for STATIC and the highest for OSPF. 

2) Defme a few fixed routing profiles and sell them as a part of sendee 
packages such as Gold, Silver, and Bronze. For instance, Gold will allow 
user to select OSPF for intra-VPN as weU as ISP edge segment. Silver 
will allow user to configure OSPF for intra-VPN segment, while RIP for 
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ISPF edge. The bronze package will permit customer to configure 
STATIC for ISP edge as well as lutra-VPN segment 

3) Provide additional services as part of a profile. For example, include 
5 firewall, intrusion detection, network address translation, proxy services, 

or other network services as part of a differentiated service package. The 
service can then be included in profiles defined as part of the semce 
package, and excluded fi:om profiles for customers that do not pay for the 
service. 

10 

Conclusion 

Systems and methods for generating and provisioning router 
configurations are disclosed. The embodiments of the invention provide 
15 advantages over previous systems. For example, the embodiments of the 

invention provide a mechanism for easily and rapidly generating configuration 
infomaation for large numbers of virtual routers and vurtual private networks 
based on profiles. In addition, the embodhnentsoftheiavention separate the 
connectivity and routing needs of each VPN, tiius significantly reduced the 
20 complexity of the network design. This separation also enables layering of 
advanced services to specific subscribers' networks. Visibility of subscriber 
services is end-to-end. The topology and routing needs of each VPN depend on 
the number and size of customer sites. 

Although specific embodiments have been illustrated and described 
25 herein, it wiU be appreciated by those of ordinary skill in the art that any 

arrangement which is calculated to achieve the same purpose may be substituted 
for the specific embodiments shown. This application is intended to cover any 
adaptations or variations of the present invention. 

The terminology used in this application is meant to include all of these 
30 enviromnents. It is to be understood that the above description is intended to be 
illustrative, and not restrictive. Many other embodiments will be apparent to 
those of skill in the art upon reviewing the above description. Therefore, it is 
manifestly intended that this invention be liriiited only by the following claims 
and equivalents thereof 

35 
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What is claimed is: 

1 . A computerized method for provisioning router configuration data, the 
method comprising: 

determining a set of site reachability data; 

defining a global routing profile; and 

generating a routing configuration based on tlie site reachability data mid 
the global routing profile. 



2. The computerized method of claim 1, further comprising defining a site 
profile and wherein generating the routing configuration includes the site profile 
in addition to the site reachability data and the global routing profile. 

3 . The computerized method of claim 1 , fijrther comprising defining an 
OSPF profile and wherein generating tlie routing configuration includes the 
OSPF profile in addition to the site reachability data and the global routing 
profile. 



4. The computerized method of claim 1, further comprising: 
adding a site to a virtual private netwo±; and 

causing the site to inherit the routing configuration generated based on 
the global routing profile. 
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5 . A computerized method for applying a routing configuration, the method 
comprising: 

generating a routing configuration; 

selecting at least one virtual router from a plurality of virtual routers; and 
5 applying the routing configuration to the selected virtual router. 



6 . A computerized method for provisioning router configuration data, flie 
method comprising: 

deteimining a set of site reachability data; 
10 defining a site routing profile; and 

generating a routing configuration based on the site reachability data and 
the site routing profile. 



7. A system for managing a virtual router, comprising: 
15 a service processing switch communicably coupled to at least one access 

router; and 

a service management system communicably coupled to the service 
processing switch and operable to: 

receive site reachability data; 
20 receive a global routing profile; 

generate a routing configuration based on the site reachability 
data and the global routing profile. 
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8. The computerized system of claim 7, fur&er comprising a customer 
network management system operable to maintain customer related network 
data. 

9. The computerized system of claun 8, wherein the customer related 
5 network data comprises site reachability data. 

1 0. The computerized system of claim 8, wherein the customer related 
network data comprises global profile data. 

.0 11. A computer-readable medium having computer executable instructions 
for performing a method for provisioning router configuration data, the method 
comprising: 

determining a set of site reachabihty data; 
defining a global routing profile; and 
5 generatmg a routing configuration based on the site reachabihty data and 

the global routing profile. 



12. The computer-readable medium of claun 1 1, wherein the method fiirther 
comprises defining a site profile aad wherein generating the routing 
configuration includes the site profile in addition to the site reachability data and 
the global routing profile. 
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13. The computer-readable medium of claim 1 1, wherein the method fiirtlier 
comprises defining an OSPF profile and wherein generating the routing 
configuration includes the OSPF profile in addition to the site reachability data 
and the global routiag profile. 

5 

14. The computer-readable mediirai of claim 1 1 , wherein the method further 
comprises: 

adding a site to a virtual private network; and 

causing the site to inherit the routing configuration generated based on 
10 the global routing profile. 



15. A computerized method for applying a routing configuration, the method 
comprising: 

generating a routing configuration; 
1 5 selecting at least one virtual router from a plurality of virtual routers; and 

applying the routing configuration to the selected virtual router. 

16. A computer-readable medium having computer executable instructions 
for performing a method for provisioning router configuration data, the method 

20 comprising: 

determining a set of site reachabiUty data; 
defining a site routing profile; and 
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generating a routing configuration based on the site reachability data and 
the site routing profile. 



5 
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